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Quality of Service Parameters for Usage with Diameter 


Abstract 


This document defines a number of Quality of Service (Q0S) parameters 
that can be reused for conveying QoS information within Diameter. 


The defined QoS information includes data traffic parameters for 
describing a token bucket filter, a bandwidth parameter, and a per- 
hop behavior class object. 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
Please review these documents carefully, as they describe your rights 
and restrictions with respect to this document. 
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1. Introduction 


This document defines a number of Quality of Service (Q0S) parameters 
that can be reused for conveying QoS information within the Diameter 
protocol [RFC3588]. The current set of QoS parameters defined in 
this document are a core subset determined to be useful for a wide 
range of applications. Additional parameters may be defined in 
future documents as the need arises and are for future study. The 
parameters are defined as Diameter-encoded Attribute Value Pairs 
(AVPs), which are described using a modified version of the Augmented 
Backus-Naur Form (ABNF), see [RFC3588]. The data types are also 
taken from [RFC3588]. 


The traffic model (TMOD) AVPs are containers consisting of four AVPs 
and provide a way to describe the traffic source. 


o token rate (r) 
o bucket depth (b) 


o peak traffic rate (p) 
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o minimum policed unit (m) 
o maximum packet size (M) 


The encoding of the <TMOD-1> and the <TMOD-2> AVPs can be found in 
Sections 3.1 and 3.2. The semantics of these two AVPs are described 
in Section 3.1 of [RFC2210] and in Section 3.6 of [RFC2215]. 


The <IMOD-2> AVP is, for example, needed by some DiffServ 
applications. 


It is typically assumed that DiffServ expedited forwarding (EF) 
traffic is shaped at the ingress by a single-rate token bucket. 
Therefore, a single TMOD parameter is sufficient to signal 
DiffServ EF traffic. However, for DiffServ assured forwarding 
(AF) traffic, two sets of token bucket parameters are needed: one 
token bucket for the average traffic and one token bucket for the 
burst traffic. [RFC2697] defines a Single Rate Three Color Marker 
(srTCM), which meters a traffic stream and marks its packets 
according to three traffic parameters -- Committed Information 
Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size 
(EBS) -- to be either green, yellow, or red. A packet is marked 
green if it does not exceed the CBS, yellow if it does exceed the 
CBS but not the EBS, and red otherwise. [RFC2697] defines 
specific procedures using two token buckets that run at the same 
rate. Therefore, two TMOD AVPs are sufficient to distinguish 
among three levels of drop precedence. An example is also 
described in the appendix of [RFC2597]. 


Resource reservations might refer to a packet processor with a 
particular DiffServ per-hop behavior (PHB) (using the <PHB-Class> 


AVP). A generic description of the DiffServ architecture can be 
found in [RFC2475], and the Differentiated Services Field is 
described in Section 3 of [RFC2474]. Updated terminology can be 
found in [RFC3260]. Standardized per-hop behavior is, for example, 
described in [RFC2597] ("Assured Forwarding PHB Group") and in 
[RFC3246] ("An Expedited Forwarding PHB"). 


The above-mentioned parameters are intended to support basic 
integrated and differentiated services functionality in the network. 
Additional parameters can be defined and standardized if required to 
support specific services in the future. 


2. Terminology and Abbreviations 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC2119 [RFC2119]. 
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3. QoS Parameter Encoding 
3.1. TMOD-1 AVP 


The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The 
structure of the AVP is as follows: 


AVP Header: 495 > 
Token-Rate } 
Bucket-Depth } 
Peak-Traffic-—Rate } 
Minimum-Policed-Unit } 
Maximum—-Packet-Size } 


TMOD-1 “= 


AAA AAA 


3.1.1. Token-Rate AVP 

The Token-Rate AVP (AVP Code 496) is of type Float32. 
3.1.2. Bucket-—Depth AVP 

The Bucket-—Depth AVP (AVP Code 497) is of type Float32. 
3.1.3. Peak-Traffic-Rate AVP 

The Peak-Traffic-Rate AVP (AVP Code 498) is of type Float32. 
3.1.4. Minimum-Policed-Unit AVP 

The Minimum-Policed-Unit AVP (AVP Code 499) is of type Unsigned32. 
3.1.5. Maximum-Packet-Size AVP 

The Maximum-Packet-Size AVP (AVP Code 500) is of type Unsigned32. 
KEN TMOD-2 AVP 


A description of the semantics of the parameter values can be found 
in [RFC2215]. The coding for the TMOD-2 AVP is as follows: 


AVP Header: 501 > 
Token-Rate } 
Bucket-—Depth } 
Peak-Traffic-Rate } 
Minimum-Policed-Unit } 
Maximum-—Packet-Size } 


TMOD-2 ::= 


AAA a e A 
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3.3. Bandwidth AVP 


The Bandwidth AVP (AVP Code 502) is of type Float32 and is measured 
in octets of IP datagrams per second. The Bandwidth AVP represents a 
simplified description of the following TMOD setting whereby the 
token rate (r) = peak traffic rate (p), the bucket depth (b) = large, 
and the minimum policed unit (m) = large when only bandwidth has to 
be expressed. 


3.4. PHB-Class AVP 
The PHB-Class AVP (AVP Code 503) is of type Unsigned32. 


A description of the semantics of the parameter values can be found 
in [RFC3140]. The registries needed for usage with [RFC3140] already 
exist and hence a new registry is not required for this purpose. The 
encoding requires that three cases be differentiated. All bits 
indicated as "reserved" MUST be set to zero (0). 


3.4.1. Case 1: Single PHB 


As prescribed in [RFC3140], the encoding for a single PHB is the 
recommended Differentiated Services Code Point (DSCP) value for that 


PHB, left-justified in the 16-bit field with bits 6 through 15 set to 
zero. 


0 1 2 3 
01234567890123456789012345678901 
KE tata tata tata tata ta tata ta tata ta tata tata ta HH 

| DSCP lo000000000| (Reserved) 
tata tata tata tata tata ta tata ta tata tata ta tata ta tata ta tata E tat 


3.4.2. Case 2: Set of PHBs 


The encoding for a set of PHBs is the numerically smallest of the set 
of encodings for the various PHBs in the set, with bit 14 set to 1. 
(Thus, for the AFlx PHBs, the encoding is that of the AF11 PHB, with 
bit 14 set to 1.) 


0 1 2 3 
01234567890123456789012345678901 
tata tata ta tata E E E E EE HH 

| DSCP Lë: 8-000) 0000. te 0] (Reserved) 
t-+—-+-4+-+4+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4+-4-4-4t-4+-4-4t-4+-4-4-4+-4-4-4-4-4-4 
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3.4.3. Case 3: Experimental or Local Use PHBs 


PHBs may not be defined by standards actions i.e., experimental or 
local use PHBs as allowed by [RFC2474]. In this case, an arbitrary 
12-bit PHB identification code, assigned by the IANA, is left- 
justified in the 16-bit field. Bit 15 is set to 1, and bit 14 is 
zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are 
zero. 


Bits 12 and 13 are reserved either for expansion of the PHB 
identification code or for other, future use. 


In both cases, when a single PHBID is used to identify a set of PHBs 
(i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 
Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 
intra-microflow traffic reordering when different PHBs from the set 
are applied to traffic in the same microflow). The set of AF1x PHBs 
[RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 
do not constitute a PHB Scheduling Class can be identified by using 
more than one PHBID. 


0 1 2 3 
H'h 2. 3% 4 956: Sf 899.08 12: 3) 4-5 6k 89. OL 2 2 bp Sr 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| PHD ID CODE |0 0 1 Of (Reserved) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


4. Extensibility 


This document is designed with extensibility in mind, given that 
different organizations and groups are used to defining their own 
Quality of Service parameters. This document provides an initial QoS 
profile with a common set of parameters. Ideally, these parameters 
should be used whenever possible, but there are cases where 
additional parameters might be needed or where the parameters 
specified in this document are used with different semantics. In 
that case, it is advisable to define a new QoS profile that may 
consist of new parameters in addition to parameters defined in this 
document or an entirely different set of parameters. Finally, it is 
also possible to register a specific QoS profile that defines a 
specific set of QoS values rather than parameters that need to be 
filled with values in order to be used. 


To enable the definition of new QoS profiles, an 8-octet registry is 
defined as a field that is represented by 4-octet vendor and 4-octet 
specifier fields. The vendor field contains an Enterprise Number as 
defined in [RFC2578], taken from the values maintained in the IANA 

Enterprise Numbers registry. If the four octets of the vendor field 
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are 0x00000000 (reserved value for IANA), then the value in the 
specifier field MUST be registered with IANA (see Section 5.2). If 
the vendor field is other than 0x00000000, the value of the specifier 
field represents a vendor-specific value, where allocation is the 
responsibility of the enterprise indicated in the vendor field. 


5. IANA Considerations 
5.1. AVP Codes 
TANA allocated AVP codes in the IANA-controlled namespace registry 


specified in Section 11.1.1 of [RFC3588] for the following AVPs that 
are defined in this document. 


Fn + 
AVP Section 

AVP Name Code Defined Data Type 
Fn nn ne A E + 
| TMOD-1 495 3.1 Grouped 

| Token-Rate Zap 3.101 Float32 | 
|Bucket-Depth 497 3.1.2 Float32 | 
Peak-Traffic-Rate 498 3.1.3 Float32 | 
Minimum-Policed-Unit 499 3.1.4 Unsigned32 
|Maximum-Packet-Size 500 ec Unsigned32 | 
| TMOD-2 501 3.2 Grouped 
|Bandwidth 502 3.3 Float32 | 
|PHB-Class 503 3.4 Unsigned32 | 
KEE + 


5.2. QoS Profile 


The QoS profile refers to a 64-bit field that is represented by 
4-octet vendor and 4-octet specifier fields. The vendor field 
indicates the type as either standards-specified or vendor-specific. 


If the four octets of the vendor field are 0x00000000, then the value 
is standards-specified and a registry will be created to maintain the 
QoS profile specifier values. The specifier field indicates the 
actual QoS profile. Depending on the value requested, the action 
needed to request a new value is: 


0 to 511: Standards Action 
512 to 32767: Specification Required 


32768 to 4294967295: Reserved 
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Standards action is required to add, depreciate, delete, or modify 
QoS profile values in the range of 0-511, and a specification is 
required to add, depreciate, delete, or modify existing QoS profile 
values in the range of 512-32767. 


IANA created such a registry and allocated the value zero (0) for the 
QoS profile defined in this document. 


Alternative vendor-specific QoS profiles can be created and 
identified with an Enterprise Number taken from the IANA registry 
created by [RFC2578] in the vendor field, combined with a vendor- 
specific value in the specifier field. Allocation of the specifier 
values is the responsibility of the vendor. 


6. Security Considerations 


This document does not raise any security concerns as it only defines 
QoS parameters and does not yet describe how they are exchanged in an 
Authentication, Authorization, and Accounting (AAA) protocol. 
Security considerations are described in documents using this 
specification. 
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Appendix A. ABNF Code Fragment 
Copyright (c) 
of the code. All rights reserved. 
Redistribution and use in source and b 
modification, 
are met: 


Redistributions of source code must 
notice, this list of conditions and 


O 


Redistributions in binary form must 
notice, this list of conditions and 
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2009 IETF Trust and the persons identified as authors 


inary forms, with or without 


are permitted provided that the following conditions 


retain the above copyright 
the following disclaimer. 


reproduce the above copyright 
the following disclaimer in 


the documentation and/or other materials provided with the 


distribution. 


names of specific contributors, may 
products derived from this software 
permission. 


THIS SOFTWARE IS PROVIDED BY THE COPYR 
‘AS IS’ 
LIMITED TO, 
A PARTICULAR PURPOSE ARE DISCLAIMED. 


Neither the name of Internet Society, 


AND ANY EXPRESS OR IMPLIED WARRANTIES, 
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 


IETF or IETF Trust, nor the 
be used to endorse or promote 
without specific prior written 


IGHT HOLDERS AND CONTRIBUTORS 
INCLUDING, BUT NOT 


IN NO EVENT SHALL THE COPYRIGHT 
INC 


OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, IDENTAL, 
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 

LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 


THEORY OF LIABILITY, WHETHER IN CONTRACT, 


STRICT LIABILITY, OR TORT 


(INCLUDING NEGLIGENCE OR OTHERWISE) 


ARISING IN ANY WAY OUT OF 


THE USE 


OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 


TMOD-1 


AA AA e A 


AVP Header: 
Token-Rate } 
Bucket-—Depth } 
Peak-Traffic-—Rate } 
Minimum-Policed-Unit } 
Maximum—-Packet-Size } 


495 > 


TMOD-2 


e e e AA 


AVP Header: 
Token-Rate } 
Bucket-Depth } 
Peak-Traffic-—Rate } 
Minimum-Policed-Unit } 
Maximum—-Packet-Size } 


501 > 
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